Infeasibility Management in E-Sourcing Systems

ABSTRACT

Systems, apparatuses, and methods for providing feedback in an electronic sourcing system. A system is configured to receive bids from users in an electronic sourcing system. Additionally, the system receives one or more rules from the users that describe desired properties of an award of one or more items. Responsive to such input, the system builds a model based at least in part on rules provided by one or more users. If one or more irreducible infeasible sets of constraints are identified in the model, where the one or more sets of irreducible infeasible constraints include the given constraint, information based on said one or more irreducible infeasible sets is output.

PRIORITY INFORMATION

This application claims benefit of priority to U.S. ProvisionalApplication Ser. No. 62/083,793, filed Nov. 24, 2014, which is herebyincorporated by reference in its entirety as though fully and completelyset forth herein.

TECHNICAL FIELD

This invention relates to improved systems and methods for e-sourcing.

DESCRIPTION OF RELATED ART

E-sourcing (electronic sourcing) systems provide ways to electronicallymanage tenders where suppliers compete for the opportunity to provideproducts and/or services. E-sourcing systems may generally assist buyersin processes such as requesting bids and other information from bidders,evaluating different award scenarios based on received information,negotiating with bidders, deciding on an award of the business, and soon. When evaluating different award scenarios, buyers may take intoaccount business policies, regulations, bidder-declared capacities,various conditions, discounts, and other factors. Further, there may berules describing the underlying properties of the tender which canrepresent a complex supply chain. Advanced e-sourcing systems aredesigned to support the computing of allocations taking such rules intoaccount.

As an example, Table 1 below depicts a sample set of rules:

TABLE 1 A sample set of rules. Rule Name Description R1 Buyer: Allocateat most 10 suppliers in total. R2 Buyer: Allocate at most 3 suppliersper country. R3 Buyer: Allocate at most 3 suppliers per product. R4Buyer: Allocate at most 1 supplier per country and product. R5 Buyer: Donot allocate any bidder more than 80% of its declared capacity. R6Buyer: Do not allocate any bidder more than 20% of its yearly turnover.R7 Buyer: Allocate at least 75% of the volume to incumbent suppliers. R8Buyer: Do not allocate bidder B1 country Co1 unless he is also allocatedat least one of countries Co5, Co17 and Co21. R9 Buyer: If a printingfacility is allocated in city Ci1, then the required amount of deliveredpaper must be allocated to Ci1. R10 Buyer: Divide allocations inproportions 70%, 20%, and 10% for each product. R11 Buyer: In Europe,allocate at most 3 bidders per country, unless I gain 100 000 USD perextra supplier and country. R12 Bidder: If I get at least 10 trucksallocated in at least 2 of western Nevada cities, I will give a 2.1%discount in California.

In many cases, mixed integer programming can be used to solve complexsets of bids and rules when such rules can be expressed in linear terms.For example, the rules in the above example can be expressed as linearconstraints. Other types of mathematical solvers such as Non-LinearProgramming are also conceivable for use in an e-sourcing system. Incases where two or more rules are contradictory, a solution may notexist and a solver may report that the problem at hand is infeasible.Even with a small number of rules, such as a scenario including rulesR1-R12 in Table 1, understanding which rules are contradictory can bedifficult. For a buyer using an e-sourcing system in a situation with amuch larger number of rules and conditions, understanding the source(s)of infeasibility and/or obtaining a “best effort” solution by relaxingsome rules is a non-trivial task.

Scenarios, Rule, and Constraints

Throughout this document, the term “rule” generally refers to arelatively high level construct typically defined by, or presented to, auser on a display of a computing device or other device. For example, R8presented above states “Do not allocate bidder B1 country Co1 unless heis also allocated at least one of countries Co5, Co17 and Co21.” Thisrepresents a relatively high level, abstract, description of particularconditions. In this case, the rule is presented as a natural languagedescription, readable by a human. In contrast, the term “constraint” maygenerally refer to a relatively low level construct used by a computeror mathematical model. For example, a constraint may take the form of anequation or inequality. In a typical case, a rule can be represented byone or more constraints, and relaxing a rule implies modifying orremoving one or more related constraints.

The term “scenario” may refer to a set of rules, bids, and/or other datawhich together define an optimization problem for calculating anallocation. As such, a scenario may describe a particular alternativefor awarding the business at hand. A scenario is infeasible if theresulting optimization problem is infeasible.

Mathematical Background

Infeasibility detection among a system of linear constraints (mixedinteger or otherwise) has been an important topic for many years. Theconcept of an Irreducible Infeasible Set (IIS) or Irreducible InfeasibleSubsystem (IIS) of constraints was defined as early as 1956 when Ky Fanpublished the paper “On Systems of Linear Inequalities” in “LinearInequalities and Related Systems”. However, despite the importance ofthe topic, very little progress was made in the development of amethodology to detect and resolve infeasibilities until the introductionof elastic programming in the 1970's, a technique that was described byG. G. Brown and G. W. Graves in their paper on “Elastic Programming: ANew Approach to Large-Scale Mixed Integer Optimization” in 1975.

Since the 1970's a number of techniques have been presented in an effortto identify infeasible sets of constraints. Such methods includebranch-and-bound, constraint addition, cycle generation, deletionfiltering, dual/shadow prices, elastic programming, feasible systempolytopes, IIS hyper-graphs, hypothesis generation, sensitivityfiltering, set covering, successive bounding, ranking and weighting.

Furthermore, it should also be noted that the IIS hyper-graph andpolytope methods may not be applicable as they require the formulationof the problem as a hyper-graph or a polytope—mathematical constructsthat are difficult for even trained mathematicians to visualize andbeyond the ability of most commercial (mixed integer) linear programmingsolvers to handle.

However, the inventors have determined that there are methods that couldbe relevant for real-world domain problems, and which could be appliedto the domain of e-Sourcing. For example, constraint addition startswith an unconstrained problem and incrementally adds constraints to theproblem, one at a time, until the problem is infeasible. The resultingset of constraints is guaranteed to be irreducible, but is notguaranteed to be the smallest irreducible set.

Another method that may be applied is deletion filtering. In deletionfiltering, constraints are removed from an infeasible model one by oneuntil the model is feasible. The remaining set of constraints with thelast deleted constraint is an infeasible set. However, the base methodhas a number of shortcomings. The method typically only finds oneinfeasible set, which is not necessarily minimal. And, like constraintaddition, it does not necessarily tell the user why the set isinfeasible.

Branch-and-Bound, an extension of the depth first search algorithm,incrementally builds a tree structure using the constraints, startingfrom an empty set, such that the left child of a node at each levelrepresents the set of constraints without the constraint associated withthe level and the right child of a node at each level represents the setof constraints with the constraint associated with the level. If thereare n constraints, the tree will have n levels and the leaf level willcontain all of the (2 to the power of n) subsets of constraints. Thealgorithm works by traversing the tree down the right-most side until aninfeasible set of constraints is found, and then searching left until aminimal such set is found. This is essentially a modified form ofconstraint addition, and while it can be altered to find multipleinfeasible sets, and infeasible sets of minimum size, this requirestracing out a subtree of exponential size and the method becomesimpractical as an exponential number of models, which could each requirea large processing time, have to be solved.

Set Covering, in infeasibility analysis, picks random points thatrepresent valid solutions to an unconstrained model and then tests eachconstraint against that point. If the constraint is violated, it isadded to a set of unsatisfied constraints. The set of all suchunsatisfied constraints is an infeasible set because it prevents asolution at that particular point. However, the set of constraintsproduced is not guaranteed to be an irreducible set of constraints, assome constraints in the set could make others unnecessary. In addition,the base model has to be solved and one or more feasible points in thebase model identified to use this method.

Infeasibility in E-Sourcing

For discussion of prior art methods in e-sourcing and comparisons to theembodiments described herein, we will use a small example for which thesource of infeasibility is quite apparent. Furthermore, for the purposeof discussing prior art methods, we assume that a priority has beenassigned to each rule.

TABLE 2 A small set of contradicting rules. Rule name DescriptionPriority R1 Allocate at least 4 units High R2 Allocate at least 3 unitsto incumbents Low R3 Allocate at most 2 units Medium

In Table 2 above three rules (R1-R3) are presented, each having anassociated priority. It is assumed that each of the three rules can besatisfied in isolation, e.g. that there are bids for at least 3 unitsfrom incumbents (i.e., current suppliers).

As can be seen in Table 2, R1 (at least 4 units) and R3 (at most 2units) cannot both be satisfied simultaneously Similarly, R2 and R3cannot both be satisfied simultaneously. However, inspecting thepriorities, a possible solution can be identified. As R1 has higherpriority, R3 may be relaxed. In this manner, a feasible solution isobtained in which both R1 and R2 are satisfied and R3 is relaxed (i.e.,is not satisfied). For example, a possible solution may be allocation of4 units, with 3 of the 4 being allocated to incumbents. While R3 is notsatisfied, this solution may be deemed the most attractive feasiblealternative given that R1 has priority over R3.

The idea of relaxing rules to obtain a feasible solution exist in priorart, but with limitations and weaknesses. For example, methods have beendescribed in which different rules are assigned priorities are graduallyrelaxed until a feasible solution is found. Such methods are, however,limited and do not necessarily lead to a good relaxation of rules.

What is, therefore, needed and not disclosed in the prior art aremethods and systems to assist users in efficiently managinginfeasibility resolution in e-sourcing that can also be used in complexsituations.

SUMMARY OF EMBODIMENTS

In one embodiment, a system is contemplated that is configured to managetenders in an electronic system. The system is configured to receiveinput from users, such as input from bidders. Such input may comprisebids, questions, and/or other data related to tenders. In addition, theinput may include rules that describe a desired property of an award ofone or more items on which the bidder is bidding. Responsive toreceiving the input, the system builds a model to determine allocationsbased on received bids. The model includes constraints based at least inpart on rules provided by bidders, and a mapping between the constraintsand rules. Responsive to attempting to solve the model, the system mayidentify one or more irreducible infeasible sets of constraints in themodel that prevent a successful allocation. If such irreducibleinfeasible sets are identified, information based on said one or moreirreducible infeasible sets is output or otherwise provided to a bidder.Such output may include an identification of one or more rules providedby a bidder that lead to the irreducible infeasible sets.

These and other features and advantages will become apparent to those ofordinary skill in the art in view of the following detailed descriptionsof the approaches presented herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and further advantages of the methods and mechanisms may bebetter understood by referring to the following description inconjunction with the accompanying drawings, in which:

FIG. 1A illustrates one embodiment of a method for determining anallocation.

FIG. 1B illustrates various embodiments of a method for determiningwhether rules violate a reference allocation and taking a responsiveaction.

FIG. 2 illustrates an infeasible two-dimensional problem with fourconstraints.

FIG. 3 illustrates the problem of FIG. 2 after relaxation of aconstraint.

FIG. 4 illustrates the problem of FIG. 3 after relaxation of anadditional constraint.

FIG. 5 illustrates one embodiment of a method for receiving and managingbids.

FIG. 6 illustrates one embodiment of an infeasibility analysis report.

FIG. 7 illustrates one embodiment of a computing system.

FIG. 8 illustrates one embodiment of a web interface.

FIG. 9 illustrates one embodiment of a sample set of rules.

FIG. 10 illustrates one embodiment of a list of scenarios.

FIG. 11 illustrates one embodiment of a web page displaying details of ascenario.

FIG. 12 illustrates one embodiment of a list of scenarios.

FIG. 13 illustrates one embodiment of an allocation report.

DESCRIPTION OF EMBODIMENTS

In the following description, numerous specific details are set forth toprovide a thorough understanding of the methods and mechanisms presentedherein. However, one having ordinary skill in the art should recognizethat the various embodiments may be practiced without these specificdetails. In some instances, well-known structures, components, signals,computer program instructions, and techniques have not been shown indetail to avoid obscuring the approaches described herein. It will beappreciated that for simplicity and clarity of illustration, elementsshown in the figures have not necessarily been drawn to scale. Forexample, the dimensions of some of the elements may be exaggeratedrelative to other elements.

While the techniques described herein are susceptible to variousmodifications and alternative forms, specific embodiments thereof areshown by way of example in the drawings and will herein be described indetail. It should be understood, however, that the drawings and detaileddescription thereto are not intended to limit the techniques to theparticular form disclosed, but on the contrary, the intention is tocover all modifications, equivalents and alternatives falling within thespirit and scope of the present embodiments as defined by the appendedclaims. The headings used herein are for organizational purposes onlyand are not meant to be used to limit the scope of the description. Asused throughout this application, the word “may” is used in a permissivesense (i.e., meaning having the potential to), rather than the mandatorysense (i.e., meaning must). Further, the use of the word “may” generallyindicates that the feature discussed may or may not be present invarious embodiments. Similarly, the words “include”, “including”, and“includes” mean including, but not limited to.

This specification includes references to “one embodiment” or “anembodiment.” The appearances of the phrases “in one embodiment” or “inan embodiment” do not necessarily refer to the same embodiment, althoughembodiments that include any combination of the features are generallycontemplated, unless expressly disclaimed herein. Particular features,structures, or characteristics may be combined in any suitable mannerconsistent with this disclosure.

Terminology. The following paragraphs provide definitions and/or contextfor terms found in this disclosure (including the appended claims):

“Comprising.” This term is open-ended. As used in the appended claims,this term does not foreclose additional structure or steps. Consider aclaim that recites: “A system comprising a display control unit . . . .”Such a claim does not foreclose the system from including additionalcomponents (e.g., a processor, a memory controller).

“Configured To.” Various units, circuits, or other components may bedescribed or claimed as “configured to” perform a task or tasks. In suchcontexts, “configured to” is used to connote structure by indicatingthat the units/circuits/components include structure (e.g., circuitry)that performs the task or tasks during operation. As such, theunit/circuit/component can be said to be configured to perform the taskeven when the specified unit/circuit/component is not currentlyoperational (e.g., is not on). The units/circuits/components used withthe “configured to” language include hardware—for example, circuits,memory storing program instructions executable to implement theoperation, etc. Reciting that a unit/circuit/component is “configuredto” perform one or more tasks is expressly intended not to invoke 35U.S.C. §112(f) for that unit/circuit/component. Additionally,“configured to” can include generic structure (e.g., generic circuitry)that is manipulated by software and/or firmware (e.g., an FPGA or ageneral-purpose processor executing software) to operate in a mannerthat is capable of performing the task(s) at issue. “Configured to” mayalso include adapting a manufacturing process (e.g., a semiconductorfabrication facility) to fabricate devices (e.g., integrated circuits)that are adapted to implement or perform one or more tasks.

“Based On.” As used herein, this term is used to describe one or morefactors that affect a determination. This term does not forecloseadditional factors that may affect a determination. That is, adetermination may be solely based on those factors or based, at least inpart, on those factors. Consider the phrase “determine A based on B.”While B may be a factor that affects the determination of A, such aphrase does not foreclose the determination of A from also being basedon C. In other instances, A may be determined based solely on B.

In practical sourcing situations, buyers are typically faced with asignificant number of business rules. In addition to this, the biddersoften have other considerations such as capacity limitations, synergies,etc. In a sourcing system supporting these types of rules, there areoften a rather large number of rules used in analyzing differentscenarios for awarding the business. Sometimes rules may becontradictory. When the number of rules is large and/or there are manyitems, bids, bidders, etc., it can be very cumbersome to resolve suchcontradictions, and some tool for infeasibility resolution is highlydesired. There at least two aspects of infeasibility resolution:

-   -   1. Obtain a feasible solution by relaxing some of the rules,        preferably with small efforts from the buyer.    -   2. Providing information about the source(s) of infeasibility.

For ease of discussion, we will discuss “a buyer”/“the buyer” as anentity which defines rules, resolves infeasibility, etc. However, it isto be understood that in practice there may be one or more buyers, oneor more groups of buyers, one or more buying organizations, etc. This“buyer” may also be referred to as a manager, user, or otherwise. Thespecific term used should not be seen as limiting the invention. Forexample, sometimes in the literature the party controlling a biddingprocess is also called bid taker. The solutions described herein canalso be used outside of e-Sourcing and buying, in which cases, the term“buyer” can be replaced by a more appropriate term, such as Manager.Examples are resource planning, scheduling, exchanges, selling, etc.Numerous such alternatives are possible and are contemplated.

It is noted that while the following discussion is centered one-sourcing, the methods and mechanisms described herein may be used inareas outside of e-sourcing. For example, the systems and methods may beused for planning, supply chain optimization, and other optimizationareas. Furthermore, the entity setting the rule need not represent abuyer, it may just as well be a bidder, analyst or otherwise.

Overview of a System for Infeasibility Resolution Obtaining a FeasibleSolution in The Presence of Contradictory Rules

As described herein, a “reference allocation”, or “reference point”,represents a potential allocation or solution. For example, such anallocation or solution may be the result of solving a scenario or it maybe a predefined allocation. Alternatively, it may simply be adescription of an allocation, such as “allocate the lowest bid for eachitem”. It is noted that a reference allocation does not need torepresent a feasible solution to any specific scenario.

A reference allocation may be used in many different ways. For example:

-   -   1. If all rules violated by the reference allocation are        identified, and all identified rules are relaxed, a feasible        problem is generated.    -   2. Information about violated rules can be useful for a buyer in        evaluating why he is unable to obtain an expected allocation, or        to guide the buyer in setting priorities for one or more rules.

FIG. 1A illustrates one embodiment of a method for determining anallocation. In the example shown, a model is received that is based onbids and rules (block 100). For example, suppliers may provide bids onone or more items that wish to supply with the bids representing theprice at which they will supply (sell) the items. Rules regardingallocations (i.e., the awarding of contracts to suppliers based on theirbids) are also received. Such rules may specify requirements on how theallocation is to be made. Using the received bids and rules, anoptimization model is received (or otherwise generated). Generallyspeaking, the model may comprise a system of equations as describedherein that includes constraints based on at least the received rules.

Having received the model, a determination is made as to whether asolution exists (i.e., is the model feasible) (block 102). If the modelis feasible, then an allocation may be generated based on a solution ofthe model (block 114). However, if the model is infeasible, then areference allocation is selected by the user or system (block 104). Invarious embodiments, the reference allocation is an initial allocationmade without regard to the allocation rules that have been received. Inthis sense, the reference allocation may be viewed as a defaultallocation. For example, such a reference allocation may be a Zeroallocation in which no awards are made. Alternatively, a referenceallocation may simply award the lowest bid for each item. Otherreference allocations may be based on previously determined allocationand/or solution to a model. These and other reference allocation will bediscussed further below.

Having made the reference allocation, a determination is then made as towhether any of the received allocation rules, have been violated.Generally speaking, each rule is examined and compared to the referenceallocation to determine if the rule is violated (block 106). In thismanner, each of the rules that are violated are identified (block 100).Having identified all rules that are violated by the referenceallocation, all of the identified rules (in some embodiments) arerelaxed (block 112). In some embodiments, relaxing a rule may includecomplete removal of the rule. In other embodiments, relaxing of a rulemay include reducing constraints imposed by the rule. For the purposesof discussion here, removal of the rule will be described. Thecomparison of rules against the reference allocation and the relaxationof the rules can be done at different levels, for example on a datastructure directly representing the rule(s) or on an equation in anoptimization model dependent on how data is received and processed invarious embodiments. As used herein, the expression “relaxing a rule”and similar expressions may refer to a direct modification of rules,modification of a representation of rules (e.g., in equations used torepresent such rules), modification of data structures used to representrules, and so on.

Once the identified rules that violate the reference allocation havebeen removed, the optimization model is then modified so that isreflects removal of these rules (block 114). Given the modified model, anew allocation is generated that is compatible with the modified modeland a solution has now been obtained (block 116).

FIG. 1B, illustrates various method to identify and relax a sub-set ofrules, based on one or more reference allocations. In the example shown,a reference allocation is used to obtain different results: (i)information about relaxed rules, (ii) a modified model, or (iii) asolution to the modified model. In block 120, an optimization modelincluding associated bids and rules is received. Generally speaking, asdescribed herein, the optimization model may include a system ofequations based on bids and rules. However, the discussion may simplydescribe the optimization and including or comprising bids and/or rules.The received rules are then compared to one or more reference allocation(block 122), and a determination is made as to whether any of the rulesare violated by the one or more reference allocations (decision block124). If no rules are violated, then some other action may be taken(block 126). However, if a rule violation is detected, then one or moreactions (denoted A) may occur.

In one embodiment, information about at least one rule that is violatedby the reference allocation may be output (block 130). Anotherpossibility is to relax at least one rule that is violated by thereference allocation (block 140), and a modified model based on therelaxed rule generated and/or output (blok 142). Yet another possibilityis to relax at least one rule that is violated by the referenceallocation (block 150), and output a result of solving the model usingthe relaxed rule (block 152). The comparison of rules against thereference allocation and the relaxation of the rules can be done atdifferent levels, for example on a data structure directly representingthe rule or on an equation in an optimization model dependent on howdata is received and processed in various embodiments.

Elastic programming is a method for handling infeasibility inmathematical programming in which constraints may be broken with apenalty and the solver may then include these violation penalties in theobjective. Using such a method, each constraint can be violated and ispenalized as a function of the magnitude of the deviation. In otherwords, a constraint may not need to be completely omitted. Rather aconstraint may be violated to different degrees at a cost. For example,assume the following linear problem:

-   -   Minimize: 2x+y

Subject to: x≧1   (1)

y≧2   (2)

x+y≦1.5   (3)

-   -   Where: x∈[0,1]        -   y∈[0,2]            Applying elastic programming to constraints (1) and (2) may            give:    -   Minimize 2x+y+100e₁+100e₂

Subject to x+e ₁≧1   (1)

y+e ₂>2   (2)

x+y≦1.5   (3)

-   -   Where: x, e₁∈[0,1]        -   y, e₂∈[0,2]            The solution to the elastic version is x=0 and y=1.5, with            e₁=1 and e₂=0.5 giving a total violation cost at 150.

Elastic programming is a means to relax a rule in variousembodiments—when the scenario is modelled using mathematical programmingand elastic programming is applied to one or more rules representing therule. As described herein, we provide a modified form of elasticprogramming For this purpose, we introduce the term EP*. Applying EP* isdefined as one or more of the following:

-   -   (i) Applying elastic programming to relax one or more        constraints in a mathematical programming problem representing        some part of a scenario.    -   (ii) Omitting the representation of some part of a scenario or        rule in the mathematical programming model.    -   (iii) Changing the scope or limit of a rule.

Omitting (parts of) the rule in the mathematical program can essentiallybe thought of as corresponding to using elastic programming with a ruleviolation penalty of zero, but technically, just omitting the rule maybe more practical. For simplicity and readability, the description ofEP* is based on the case where a penalty (if used) is proportional tothe deviation from the rule, and where rules can be omitted. Othervariants are possible and are contemplated, such as using a penalty ifthe rule is broken and then adding no further penalty based on degree ofdeviation, using combinations of different such penalties, or usepenalties based on combinations of deviations of different rules. Thevariants described here are exemplary only and should not be seen aslimiting.

In EP*, a rule violation penalty can be a fixed number, user-defined,derived by the system, or otherwise. One alternative would be to use auser-defined value whenever defined, and a system default valueotherwise. The variant above that obtains a feasible problem by applyingEP* to all rules that are violated by the reference point problem isdenoted AutoRelaxByAlloc. The mathematical programming problem resultingfrom AutoRelaxByAlloc is feasible as there is at least one feasiblesolution: the solution corresponding to the reference allocation.

AutoRelaxByAlloc is now described in a small example. In FIG. 2, aninfeasible two-dimensional problem with four constraints (C1-C4) isshown. We also show two reference points, P1 and P2, which maycorrespond to reference allocations for a corresponding scenario. As canbe seen, P2 is not feasible due to constraint C3, and P1 is not feasibledue to either of constraints C2 and C3.

Next, in FIG. 3, AutoRelaxByAlloc with reference point P2 has beenapplied. In order to make P2 feasible, EP* has been applied on C3 (herethe constraint C3 has been relaxed, and removed from the figure). P2 isnow a feasible solution, and there is a region around P2 which is alsofeasible. For the case that the rule violation penalty applied by EP* onC3 is high enough, the solver will return the solution being the topcorner of the triangle forming the feasible region around P2, as thismay be deemed to violate C3 the least.

In FIG. 4, the reference point P1 is used. For this case, EP* is appliedand both C2 and C3 are relaxed, and there is a larger feasible region.The AutoRelaxByAlloc method can hence be used to conveniently obtain afeasible solution with minimum input from the buyer, or allowing thebuyer to set penalties at a detailed level if so desired.

In various embodiments, AutoRelaxByAlloc can be invoked on request, forexample when the buyer has been informed that his original scenario wasinfeasible, performed automatically by the system as soon as a solveattempt concludes that the problem is infeasible, or be triggered bysome other event. Once the allocation is obtained, it can be reported bythe system in various ways. This can include all types of reports on theallocations and payments as well as reports on deviations from limits ofthe relaxed rules.

Based on the above discussion, below is a sample description of abidding and allocation process. It is noted that the presented exampleis relatively simple for purposes of discussion. Those skilled in theart will appreciate that in various situations there may be many morebidders, items and rules than discussed below. In this example there aretwo bidders that are bidding to serve as supplier for five items. Theillustrated bid prices (100-104 and 90-94) in this table are arbitraryand are provided simply for purposes of discussion. Each bidder hasprovided bids for supplying the items as follows:

TABLE 4 Supplier Bids Bidding Suppliers Incumbent Supplier New SupplierItems Bid (Dollars) Bid (Dollars) Item 1 104 90 Item 2 103 91 Item 3 10292 Item 4 101 93 Item 5 100 94

In table 4 above, Incumbent Supplier and New Supplier have each providedbids for the sale of each of five items, Item 1-Item 5. In this example,we assume that the objective of the optimization is to minimize cost,though other objectives are possible and are contemplated. In thisexample, the cost of an item is defined as either (i) the payment to theallocated bid as stated in the bid, or (ii) 10,000 per non-allocateditem if an item is not allocated. For example, if Item 1 is notallocated in a given allocation, then a cost of 10,000 is applied. IfItems 1 and 2 were not allocated, then a cost of 2×10,000=20,000 wouldbe applied, and so on. As with the above bids, the penalty mentionedhere (10,000) is simply provided for purposes of discussion. In thisembodiment, there is no penalty associated with violation of an omittedrule (discussed in greater detail below). Rather, omitted rules areignored and treated as though they do not exist. However, as will befurther described below, penalties associated with rules that are madeelastic may also be included in the cost and in some embodiments suchcosts could be associated with omitted rules as well if desired

With no other rules present, the minimum cost occurs if the bids fromNew Supplier (the lowest bidder on all items) are allocated on all fiveitems, resulting in a total cost of 90+91+92+93+94=460.

Next, assume that a buyer has defined a scenario S, including the rulesof Table 2, to be used in the allocation calculation. Hence scenario Scontains:

Rule name Description R1 Allocate at least 4 units R2 Allocate at least3 units to incumbents R3 Allocate at most 2 units

On review of the above rules it can be seen that scenario S is notfeasible. For example, R1 and R3 cannot both be satisfied as R1 requiresallocation of at least 4 units and R3 requires allocation of at most 2units. In some embodiments, detection of such an infeasibility mayinclude responding in one or more of a variety of ways—such as byproducing a report when an attempt to calculate allocations is made.

We will now describe six different embodiments for resolving theinfeasibility of scenario S. The described embodiments are based onthree different reference allocations and two relaxation methods,resulting in six combinations. It is noted that many possible referenceallocations and relaxation methods are possible based on a variety ofbusiness considerations. These and other reference allocations andmethods are possible and are contemplated. It is also noted thattechniques to resolve infeasibility may be done after infeasibility hasbeen detected, or such techniques may be applied without testing orknowledge of whether or not the allocation calculation is infeasible.Resolution of an infeasibility can be triggered manually orautomatically. These, and other variants are possible and contemplated.As will be seen, the described methods and mechanisms may provide ahighly efficient approach for determining a lowest cost allocationwithin the context of given conditions.

First, we describe three different reference allocations (as shown inTable 5) for use in resolving infeasibilities. In the table below, a “1”indicates that the supplier has been allocated the corresponding item(s)and a “0” indicates that the supplier has not been allocated thecorresponding item. It is noted that other types of allocations such assplit allocations, over-allocations, partial allocations, etc., are alsopossible and contemplated, but are not described in this example forease of discussion. In addition, while three different referenceallocations and two different relaxation methods are discussed, a givenprocess may only use one type of reference allocation and relaxationmethod. However, embodiments are possible where multiple approaches maybe used either in parallel or according to some sequence.

TABLE 5 Reference Allocations Reference Reference Reference Allocation AAllocation B Allocation C Incumbent New Incumbent New Incumbent NewSupplier Supplier Supplier Supplier Supplier Supplier Item 1 0 0 0 1 1 0Item 2 0 0 0 1 1 0 Item 3 0 0 0 1 1 0 Item 4 0 0 0 1 1 0 Item 5 0 0 0 11 0

As seen from the above in Table 5, reference allocation A is allocatingnothing to each supplier, reference allocation B is allocating each itemto the lowest bid (i.e., New Supplier in this example), and referenceallocation C is allocating each item to Incumbent Supplier. In theembodiments of this example, the reference allocations are definedwithout regard to any specific allocation rules defined by the buyer. Invarious embodiments, such reference allocations may be pre-defined inthe sourcing platform. In other words, it may be predetermined that agiven reference allocation to be used is to “allocate nothing”,“allocate lowest bid”, “allocate incumbent supplier”, or otherwise. Inother embodiments, a reference allocation to be used may be based onsome rules or conditions, and/or may be the result of earlier allocationcalculation(s).

As noted above, in addition to three reference allocations, tworelaxation methods may be used,: (i) omit all violated rules, and (ii)apply elastic programming to (representations of) violated rules with apenalty for violation of the rule. As an example, a penalty of 100,000per unit for violation of a rule may be applied. So, for example, if arule requiring allocation of at least 4 units is violated and theallocation is of 2 units, then the rule is violated by a measure of 2units which incurs a penalty of 2×100,000=200,000. Similarly, if anallocation of 7 units were made, then the rule would be violated by ameasure of 3 units which would incur a penalty of 3×100,000=300,000. Thepenalty of 100,000 is an example only. Different penalties may be usedin different embodiments. Penalties may also vary between differentrules to reflect some type of priorities. Given the above descriptionsof the reference allocations and relaxation methods, we now describe theresulting six combinations as shown in Table 6.

TABLE 6 Six sample embodiments for resolving infeasibility of scenarioS. Reference Relaxation Embodiment Allocation method 1 A Omit 2 AElastic 3 B Omit 4 B Elastic 5 C Omit 6 C Elastic

In each of the six embodiments, resolving infeasibility includesidentifying which rules are violated by the reference allocation used inthe give embodiment.

In embodiments 1 and 2, we use reference allocation A. By comparing theabove rules to reference allocation A, we can see that rules R1 and R2are violated. R1 is violated as it requires the allocation of at least 4units, but reference allocation A allocates 0 units. R2 is violated asit requires allocation of at least 3 units to incumbents and referenceallocation A allocates 0 to incumbents. Rule R3 is not violated as itrequires allocation of at most 2 units and reference allocation Aallocates 0 units.

In embodiments 3 and 4, we use reference allocation B. By comparing theabove rules to reference allocation B, we can see that rules R2 and R3are violated. R2 is violated as it requires allocation of at least 3units to incumbents and reference allocation B allocates 0 units toincumbents. R3 is violated as it requires allocation of at most 2 unitsand reference allocation B allocates 5 units. Rule R1 is not violated asit requires allocation of at least 4 units and reference allocation Ballocates 5 units.

In embodiments 5 and 6, we use reference allocation C. By comparing theabove rules to reference allocation C, we can see that R3 is violated asit requires allocation of at most 2 units and reference allocation Callocates 5 units. R1 is not violated as it requires allocation of atleast 4 units and reference allocation C allocates 5 units. R2 is notviolated as it requires allocation of at least 3 units to IncumbentSupplier and reference allocation C allocates 5 units to IncumbentSupplier.

Table 7 below summarizes the comparisons between the above describedrules and reference allocations.

TABLE 7 Rule Violations Reference Reference Reference Allocation AAllocation B Allocation C R1 Violated Not violated Not violated R2Violated Violated Not violated R3 Not violated Violated Violated

In each of the six embodiments, having identified which rules areviolated by a given allocation, the violated rules are relaxed. Asdescribed above in Table 6, the relaxation methods used by the exampleembodiments are to either to omit violating rules (“Omit”) or make themelastic with a penalty (“Elastic”). In various embodiments when using anElastic relaxation method, allocations may seek to minimize the penaltyassociated with violation of Elastic rules when possible. As a result ofthe relaxation, we may say that we have a relaxed version, ScenarioRelaxed (“SR”), of scenario S.

Following relaxation, a new allocation calculation is made based on SR.The result is shown in Table 8 where “Incumbent Supplier” is abbreviatedas “Inc”, and “New Supplier” is abbreviated “New”.

TABLE 8 Allocations for scenario SR in six example embodiments. Embodi-Embodi- Embodi- Embodi- Embodi- Embodi- ment 1 ment 2 ment 3 ment 4 ment5 ment 6 Inc New Inc New Inc New Inc New Inc New Inc New Item 1 0 1 0 00 1 0 1 0 1 0 1 Item 2 0 1 0 0 0 1 0 0 0 1 0 0 Item 3 0 0 0 0 0 1 1 0 10 1 0 Item 4 0 0 1 0 0 1 1 0 1 0 1 0 Item 5 0 0 1 0 0 1 1 0 1 0 1 0

In embodiment 1, the violated rules R1 and R2 are omitted. R3 (allocateat most 2 units) remains and limits the total allocation to 2 items,leaving 3 items unallocated at a cost 3×10,000=30,000 (penalty fornon-allocation of items). As noted above, the objective in thesediscussed scenarios is to minimize cost. Therefore, 2 items (Item 1 andItem 2) are allocated to the lowest bid (i.e., New Supplier), resultingin a total cost of 90+91+3×10 000=30,181. Accordingly, by using thereference allocation discussed above, rules that prevent a feasiblesolution are readily identified and removed, and a feasible solution isdetermined in an efficient manner Given the conditions of the scenarioand embodiment, the resulting total cost of the solution is guaranteedto be a lowest cost solution which may be deemed optimal in the givencontext. As will be seen in the following, the other embodimentslikewise provide a very efficient approach to determining a solution towhat was originally determined to be infeasible.

In embodiment 2, the violated rules R1 and R2 are made elastic with apenalty of, for example, 100,000. R3 remains and serves to limit thetotal allocation to 2 items which will leave 3 items unallocated at cost3×10,000=30,000. Regardless of which of the 2 items we allocate,allocation of 2 items will result in R1 (allocate at least 4 units)being violated by 2 units at a cost of 2×100,000=200,000. Therefore, R1will have no impact on which items are allocated. However, to minimizethe impact of violating the elastic version of rule R2 (allocate atleast 3 units to incumbent), the 2 units to be allocated will beallocated to Incumbent Supplier. Therefore, R2 will still be violated by1 unit at a cost/penalty of 100,000. To minimize cost (according to thepresent scenario and embodiment), items 4 and 5, having the lowest bids,are allocated to the incumbent supplier at a total cost of101+100+3×10,000+2×100,000+100,000=330,201.

In embodiment 3, rule R1 remains unchanged and rules R2 and R3 areomitted. The solver can hence allocate all items at lowest cost. As aresult, all items are allocated to New Supplier at cost90+91+92+93+94=460.

In embodiment 4, rule R1 remains and rules R2 and R3 are made elasticwith a penalty of 100,000. With reasoning analogous to the above it canbe seen that the lowest cost solution is to allocate Item 1 to NewSupplier, and Items 3, 4 and 5 to Incumbent Supplier. The cost includesa penalty of 0 for R2, 200,000 for R3, and 10,000 for one unallocateditem. Therefore, the total cost is90+102+101+100+10,000+200,000=210,393.

In embodiment 5, rules R1 and R2 remain and rule R3 is omitted. Theresulting allocation is Item 1 and 2 to New Supplier, and Items 3, 4,and 5 to Incumbent Supplier, resulting in a total cost of90+91+102+101+100=484.

Finally, in embodiment 6, rules R1 and R2 remain and rule R3 is madeelastic with a penalty of 100,000. This results in the same allocationand cost as for Embodiment 4.

As seen above, the role of the reference allocation in these exampleembodiments is to determine what rules to relax. Once that has beendone, the reference allocation may have no further role in theseembodiments.

In addition to the above, the methods and mechanisms described hereincan also be used iteratively. Assume for example we refer to the set ofrules for scenario S1 as R_(S1) and an allocation to scenario S1 asA_(S1).

A sample process may be as follows:

-   -   1) The buyer sets up a scenario, termed “BASE”, in which        R_(BASE) expresses one or more rules of the current tender.        Examples of such rules can be balance rules between different        parts of a supply chain: for example in order to enable the        allocation of a certain production bid, matching allocations of        required raw material bids must also be allocated.    -   2) Scenario BASE turns out to be infeasible. The buyer then uses        the above described method using zero allocations (allocate        nothing) as a reference allocation(s). The resulting allocation,        A_(BASE), is concluded acceptable, even though it may be that        case that, for example, a minor set of the desired sourced items        cannot be bought as part of the current tender.    -   3) The buyer sets up a second scenario, termed “AsIs”. This        scenario uses all rules of the rule set R_(BASE) which are not        violated by the new reference allocation A_(BASE). This set of        rules is named R′_(BASE). The buyer then adds one or more rules        that indicate incumbent suppliers should maintain their        incumbent allocations as specified by A_(BASE).    -   4) The second scenario, AsIs, turns out to be infeasible. The        buyer then uses one of the methods and/or mechanisms described        herein to solve the scenario with A_(BASE) as a reference        allocation. As a consequence, all rules requiring that        incumbents should keep their shares which are in conflict with        A_(BASE) are relaxed. A new allocation is then made, A_(AsIs).        On running different reports on A_(AsIs) the buyer may detect        that all expected AsIs allocations may not be fulfilled because        all the incumbents had not rebid on all of their current        contracts. The buyer might then want to contact selected        incumbents and encourage them to rebid and then rerun the AsIs        scenario. It may also/alternatively be the case that AsIs        reveals problems in the set-up of BASE and that R_(BASE) rules        need corrections and the process should restart at step 1. Once        A_(AsIs) is determined to be acceptable, the buyer continues to        step 5.    -   5) The buyer sets up a third scenario, termed “Preferred”, which        uses the rules of R′_(BASE) plus one or more other rules (e.g.,        preferred business rules). Assume also that scenario Preferred        is infeasible. The buyer then uses the methods and/or mechanisms        described herein with A_(AsIs) as a reference allocation. Note        that the buyer in this example made a choice to start from        R′_(BASE) rather than R_(AsIs). This means that the particular        rules of keeping incumbent allocations introduced in the AsIs        scenario are not enforced, but that A_(AsIs) is a feasible        solution and that the rules introduced for scenario Preferred        are only relaxed when conflicting with A_(AsIs). The rules        R′_(BASE) are enforced and met in an allocation, A_(Preferred),        but the rules R_(AsIs) need not be.

It is also conceivable to automate the semi-manual process above. Thatis, define all set of rules, R_(BASE), R_(ASIS), and R_(Preferred) priorto beginning that above process, and define what reference allocationsto use when, etc.

Identifying Sources of Infeasibility

As described above, the approach based on one or more referenceallocations can provide information about which rules were violated, andto what degree, in order to obtain a feasible solution. Though it can bevery useful to obtain such a “best effort” feasible solution, this issometimes not very informative for the user. In tenders with greatcomplexity, the fact that a certain rule had to be violated can come asa surprise, and in order to understand why it was violated, moreinformation (e.g. what other rules a specific rule is contradicting)would be very useful.

In various embodiments, a sourcing system can be configured toautomatically take infeasibility resolution actions if a user attemptsto solve a scenario which turns out to be infeasible. Such an actioncould, for example, be to relax rules using a reference allocation asdiscussed above. It could also be to inform the user about sources ofinfeasibility. The latter can for example be in the form of a reportformatted in a suitable way for direct display on a screen or fordownload.

In one embodiment, the method for providing information about thesource(s) of infeasibility can be based on expressing high level rulesas a Mathematical Programming problem using, for example, Mixed IntegerProgramming (e.g. as described in Andersson, Arne, Mattias Tenhunen, andFredrik Ygge. “Integer programming for combinatorial auction winnerdetermination.” MultiAgent Systems, 2000. Proceedings. FourthInternational Conference on. IEEE, 2000), and then maintain a mappingbetween (i) high-level rules and (ii) constraints in the MathematicalProgramming problem. Such a mapping could look like that shown in Table9 below:

TABLE 9 A mapping between rules and constraints. Constraint Stems fromB1_I1 + B1_I2 + B1_I3 + B1_I4 <= 3.5 Rule A B1_I1 + B1_I2 + B1_I3 >= 3Rule B B1_I1 + B1_I2 + B1_I3 + B1_I4 <= 2 Rule C B1_I1 − B1_I5 = 0

Next, one or more Irreducible Infeasible Sets (IIS) of constraints,sometimes called Irreducible Inconsistent Subsystem, are identified. Theidentification of IIS for a Mixed Integer Programming problem can bedone with any of a variety of available Mixed Integer Programmingsolvers, or by some special purpose algorithm.

Generally speaking, in the process above when one or more IrreducibleInfeasible Sets have been identified, the result is output by beingsaved to a machine readable media in a proper format or shown on adisplay of a computing device. One embodiment of such a method isdepicted in FIG. 5. FIG. 5 illustrates a method 500 that includesreceiving bids and rules (block 502), and a model builder electronicallyconstructing a model including constraints based on the rules, and amapping between the rules and constraints (block 504). One or moreirreducible sets of constraints are then identified (block 506), andinformation about the identified irreducible infeasible sets isgenerated, stored, and/or output, etc. (block 508).

For the case of a complex rule, it may be translated to many constraintsmapping to the same rule (cf. Rules 3 in Table 3). For the case of asimple rule, it may be translated directly as a bound on a variable.Hence, variable bounds can map to one or more rules. In variousembodiments, all rules may not need to be modeled in the mathematicalprogramming problem, but they may be maintained separately forefficiency. Call this set of separately maintained rules, S_(R). Oneexample of a rule in S_(R) could be a “Reject Bids” rule, which maycause one or more bids not to appear at all in the mathematicalprogramming problem. Information about S_(R) can be added once themathematical programming solver has returned one or more IIS. This canbe done optimally (for example by performing an analysis of rules inS_(R)) or in some approximate way (for example by indicating where thereare bids affected by rules in S_(R)).

Some rules may have a repetition. An example of such a rule could be“Allocate at most 3 winners per country”. In this case, the mapping willalso preferably contain enough information to derive which part of therepetition (such as country) a constraint maps to in order to provide amore accurate reporting, further illustrated below.

Once the IIS have been identified, different types of output(s) andreports can be produced. These may be in many forms—from a simplemessage directly on a display, to an extensive, formatted, report. Itcan also be visible in an interface for viewing and/or editing rules, sothat, for example, rules that are part of one or more infeasible set(s)are highlighted. Furthermore, possible changes of the limits of one ormore rules being part of an infeasible set of rules may be suggested orautomatically performed based on an analysis of the problem at hand.

It some cases it may be advantageous to report several IIS in order toenable the buyer to resolve multiple sources of infeasibility at thesame time. In practice, a reported infeasibility may reveal errors inproject set-up, data problems, or other errors or problems which shouldbe corrected. One example of an IIS report in a spreadsheet-like formatis shown in FIG. 6. In addition to what is shown in the sample report,the report can contain other information, such as the number of bidsthat occur in all of the conflicting rules. FIG. 6 illustrates oneembodiment of an infeasibility analysis report 600 in atable/spreadsheet format. In the sample report shown, rules R1 and R2are identified as contradictory (602), rule R17 is identified as being arule that cannot be fulfilled (604), and rules R3, R12, and R13 are alsoidentified as contradictory (606).

The method of identifying sources of infeasibility can be combined withthe above discussed methods in different ways. For example, anidentification of sources of infeasibility can allow the buyer to setspecific rule violation penalties on some of them.

Sample System Deployment

Turning now to FIG. 7, one embodiment of a system that may include themethods and mechanisms described herein is shown. A system of the typedescribed here can typically support hundreds of users simultaneously,which may have many different roles and may be working in differentprojects. As shown in FIG. 7, the sourcing system 700 is connected tothe Internet via a connection including a firewall 702. Web pages forbidders, buyers, and other users can be produced in a web-server 706. Abackend server 708 can receive data and signals from the web-server 706and store data to a database. In this example, a server cluster 712(e.g., SQL based or otherwise) including storage area network 714 isshown that may store a database. In addition, the backend server 708 maybe configured to perform different forms of processing and may also beconfigured to initiate jobs on other computers.

For example, additional (worker) servers 710 may be utilized forprocessing tasks and/or storing data. Still further, cloud based servers704 may be utilized for processing tasks and/or storing data. Further,the backend server may also be configured to manage scheduling ofdifferent tasks, such as closing the system for bidding in a specificproject. The worker servers 710 can perform computationally intensivetasks, such as solving optimization problems or performing differentforms of infeasibility analysis, or any other desired tasks. The systemcan be dynamic and add hardware dynamically at runtime. This can be inthe form of rented computers from a cloud server provider. The servercluster (or other forms of database hardware) generally manages thelonger term storage of data. In the example shown, one or more elementswithin block 720 may referred to as a processing system. In someembodiments, the backend server 708 generally performs processing tasks.In other embodiments, worker servers 710 may be used for performing oneor more tasks. Still further, in some embodiments, cloud based servers704 may be used for performing processing tasks.

Depending on the configuration, bidders may be allowed to place bidsthrough a web-interface 800 such as that shown in FIG. 8, or via uploadsof bid forms in one or more designated formats. Submitted bids can bereceived via the web-server, processed and verified in the backendserver, and stored by the database hardware.

The buyer may be allowed to express different desired properties of theallocation of business. A sample set of rules expressing such desiredproperties is shown in FIG. 9. Such rules can be edited directly on aweb-page, submitted via upload of documents or using any other suitablemethod. Submitted rules can be received via the web-server, processedand verified by the backend server, and stored by the database hardware.

FIG. 10 illustrates one embodiment of a list of scenarios. The buyer canbe allowed to compare the consequences of applying different set ofrules, by applying them differently in different scenarios. Suchscenarios can be edited directly on a web-page, submitted via upload ofdocuments or using any other suitable method. Submitted scenarios can bereceived via the web-server, processed and verified by the backendserver, and stored by the database software. FIG. 10 shows such apossible list of scenarios. Exact rule settings not shown, but the namesof the scenarios give some guidance in the example. For example,scenario 1 is a cherry pick scenario (a commonly used term denotingawarded the lowest possible bid for every item without any rules orother limitations). Then scenario 2 is limiting the allocation to twowinners. As a consequence of this, the payment raises from 2,017,246 USDto 2,035,246 USD. Similarly the other scenarios show trade-offs betweendesirable properties and cost. Scenario (index) 5 of FIG. 10 isinfeasible, i.e. contains contradicting rules and hence does not have asolution.

If, for example, a buyer initiates the solving of a scenario by pushinga button on a web-page, the information can be received by theweb-server and processed by the backend server. The backend server maythen update the status of the solve job via the database hardware. Itcan also schedule the solving to be performed by a worker server. Theworker server can receive a job description, read required data from thedatabase, solve the scenario, output the result to the databasehardware, and update the job status when appropriate.

FIG. 11 shows a sample web-page displaying some details of scenario 5.Status is displayed as Infeasible. The user is offered some help forinfeasibility resolution. In this example, an Infeasibility Analysisreport is available. This can be implemented to be done automatically bythe system when the scenario was concluded infeasible, or to be donemanually on request by the user. The content of this report can be ofthe type displayed in FIG. 6. In FIG. 11 there is also provided thepossibility of solving the scenario using a reference allocation. From ahardware processing perspective, the relaxation of rules and solving therelaxed model can be similar to the processing of a standard solve of ascenario.

In FIG. 12, the scenarios of FIG. 10 are shown again, but now scenario 5has been solved using a relaxation based on a reference allocation“Zero”. To analyze the outcome in more details, an e-sourcing system canallow for the production of different reports. If, for example, a buyerinitiates report generation of a scenario by pushing a button on aweb-page, the information can be received by the web-server andprocessed by the backend server. The backend server can then update thestatus of the job via the database hardware. It can also schedule thesolving to be performed by a worker server. The worker server canreceive a job description, read required data from the database, solvethe scenario, output the result to the database hardware, and update thejob status when appropriate.

One such report is shown in FIG. 13. In this example, two columns perscenario are displayed: the allocated share of the volume in %, and thepayment in USD. From the report, it can for example be seen that forscenario 2, the rule of max 2 winners is fulfilled. For scenario 5 itcan be noted that all rules could not be fulfilled (as expected sincethe scenario contains contradicting rules and is infeasible). If weassume that reference allocation Zero means no allocation, using thisreference implies relaxing the rules “Min 75% to bidder 1”, and “Min 5%to each of bidder 6 & 7”. In this particular example, the solver found asolution by violating one constraint in the rule “Min 5% to each ofbidder 6 & 7”, namely the constraint on min 5% to bidder 6.

It is noted that the above-described embodiments may comprise software.In such an embodiment, the program instructions that implement themethods and/or mechanisms may be conveyed or stored on a computerreadable medium, or on multiple computer readable media. Numerous typesof media which are configured to store program instructions areavailable and include hard disks, floppy disks, CD-ROM, DVD, flashmemory, Programmable ROMs (PROM), random access memory (RAM), andvarious other forms of volatile or non-volatile storage.

In various embodiments, as described one or more portions of the methodsand mechanisms described herein may form part of a cloud-computingenvironment. In such embodiments, resources may be provided over theInternet as services according to one or more various models. Suchmodels may include Infrastructure as a Service (IaaS), Platform as aService (PaaS), and Software as a Service (SaaS). In IaaS, computerinfrastructure is delivered as a service. In such a case, the computingequipment is generally owned and operated by the service provider. Inthe PaaS model, software tools and underlying equipment used bydevelopers to develop software solutions may be provided as a serviceand hosted by the service provider. SaaS typically includes a serviceprovider licensing software as a service on demand. The service providermay host the software, or may deploy the software to a customer for agiven period of time. Numerous combinations of the above models arepossible and are contemplated.

Although the embodiments above have been described in considerabledetail, numerous variations and modifications will become apparent tothose skilled in the art once the above disclosure is fully appreciated.It is intended that the following claims be interpreted to embrace allsuch variations and modifications.

What is claimed is:
 1. A computer-implemented method of conductinge-sourcing comprising: receiving via a computing device from a bidder abid on an item; receiving via a computing device a rule that describes adesired property of an award of one or more items; a model builderelectronically constructing a model including a plurality ofconstraints, said plurality of constraints including: a given constraintbased at least in part on said rule; and a mapping between said rule andsaid given constraint; subsequent to identifying one or more irreducibleinfeasible sets of constraints in the model, where the one or more setsof irreducible infeasible constraints include the given constraint,outputting information identifying one or more incompatible constraints.2. The method of claim 1, wherein said model comprises a mixed integerprogramming problem.
 3. The method of claim 1, wherein said identifyingis done using a mixed integer programming solver.
 4. The method of claim1, further comprising the model builder constructing a non-linearprogramming problem.
 5. The method of claim 1, wherein said identifyingis done using a non-linear programming solver.
 6. The method of claim 1,wherein said information comprises an identification of constraints insaid one or more irreducible infeasible sets and said mapping.
 7. Themethod of claim 1, wherein the one or more sets of irreducibleinfeasible sets of constraints are caused by at least one rule, and saidinformation includes an identification of the at least one rule.
 8. Themethod of claim 1, wherein said information comprises a report in theform of a spreadsheet, text document, word processor document, or pdffile.
 9. The method of claim 1, wherein the one or more irreducibleinfeasible sets of constraints include one or more rules, and whereinthe method further comprises relaxing one or more of the rulesidentified as part of an infeasible set of rules.
 10. A computing systemcomprising: a data store configured to store data; and a processingsystem, wherein the processing system is configured to: receive via acomputing device from a bidder a bid on an item; receive via a computingdevice a rule that describes a desired property of an award of one ormore items; construct a model including a plurality of constraints, saidplurality of constraints including: a given constraint based at least inpart on said rule; and a mapping between said rule and said givenconstraint; subsequent to identifying one or more irreducible infeasiblesets of constraints in the model, where the one or more sets ofirreducible infeasible constraints include the given constraint, outputinformation identifying one or more incompatible constraints.
 11. Thecomputing system of claim 10, wherein said model comprises a mixedinteger programming problem
 12. The computing system of claim 10,wherein said identifying is done using a mixed integer programmingsolver executed by the processing system.
 13. The computing system ofclaim 10, wherein the processing system is further configured toconstruct a non-linear programming problem.
 14. The computing system ofclaim 10, wherein said identifying is done using a non-linearprogramming solver executed by the processing system.
 15. The computingsystem of claim 10, wherein said information comprises an identificationof constraints in said one or more irreducible infeasible sets and saidmapping.
 16. The computing system of claim 10, wherein the one or moresets of irreducible infeasible sets of constraints are caused by atleast one rule, and said information includes an identification of theat least one rule.
 17. The computing system of claim 10, wherein saidinformation comprises a report in the form of a spreadsheet, textdocument, word processor document, or pdf file.
 18. The computing systemof claim 10, wherein the one or more irreducible infeasible sets ofconstraints include one or more rules, and wherein the method furthercomprises relaxing one or more of the rules identified as part of aninfeasible set of rules.
 19. One or more non-transitory computerreadable media comprising program instructions executable to: receivevia a computing device from a bidder a bid on an item; receive via acomputing device a rule that describes a desired property of an award ofone or more items; construct a model including a plurality ofconstraints, said plurality of constraints including: a given constraintbased at least in part on said rule; and a mapping between said rule andsaid given constraint; subsequent to identifying one or more irreducibleinfeasible sets of constraints in the model, where the one or more setsof irreducible infeasible constraints include the given constraint,output information identifying one or more incompatible constraints. 20.The one or more non-transitory computer readable media as recited inclaim 19, wherein said information comprises an identification ofconstraints in said one or more irreducible infeasible sets and saidmapping.